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mines a unique storage location for storing preference 
information for an object-oriented application, without 
resorting to the requirement of having a central authority 
assign a unique designation for the application and without 
requiring the coding of storage location information into the 
application. The server stores a plurality of object-oriented 
end user applications for downloading to user stations and it 
further stores configuration preferences for the end user 
applications in the context of different groups and subgroups 
of users. A profile manager al an administrators station is 
arranged to execute a configuration application for an end 
user application, whereby the administrator can specify 
configuration preferences for the end user application in the 
context of different groups and subgroups of system users. 
When a set of configuration preferences is to be saved on the 
server, a unique location for storing the configuration pref- 
erences is determined for the end user application in a 
selected context by retrieving the fully qualified class name 
of the end user application from an object on the adminis- 
trator's station which represents the configuration applica- 
tion. Then combining the fully qualified class name with the 
selected context to form a key. The key is then mapped in a 
prescribed manner to generate the unique storage location 
address for the application and context. 
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CLIENT-SERVER SYSTEM WITH CENTRAL 
APPLICATION MANAGEMENT AND USING 
FULLY QUALIFIED CLASS NAMES OF 
OBJECT-ORIENTED APPLICATIONS FOR 
DETERMINING PERMANENT SERVER 
STORAGE LOCATIONS FOR APPLICATION 
CONFIGURATION INFORMATION 

TECHNICAL FIELD 

The invention relates generally to toe fields of personal 
computing and networking. Specifically, it relates to the new 
and evolving field of network computing, in which desktop 
computer users use a personal computer, possibly diskless, 
connected to a network such as a corporate intranet, the 
Internet, or to an network or Internet Service Provider (ISP) 
to gain access to applications which are then executed on the 
desktop computer More specifically, the invention relates to 
server-based storage of software preferences (configuration 
data) for software retrieved from a server and executing at 
the desktop computer. 

BACKGROUND OF THE INVENTION 

The field of network computers is presently in its infancy. 
However, it is expected to evolve rapidly, especially in the 
corporate environment, for a number of reasons. The expec- 
tation is that as companies and possibly individual users 
reach hardware and software upgrade points, it will be more 
efficient and less expensive to move to this new field, rather 
than upgrade in the traditional way with disk equipped 
computers and locally stored and administered software 
applications. For example, in the corporate environment, a 
user can be connected to a corporate intranet, using, for 
example, the TCP/IP and HTTP protocols of the Internet, 
and download software applications as they are needed 
directly from a network server to the desktop computer. An 
application is executed on the desktop in the traditional 
manner by the user to perform useful work. An advantage of 
this configuration is that network computers are substan- 
tially less expensive than traditional disk equipped comput- 
ers. It might also cost less to purchase the required number 
of software licenses for users, rather than purchase indi- 
vidual copies of software for each user. Certainly, the 
software administration problems that attend large numbers 
of corporate users will be substantially reduced. At the 
present time, each user of a disk equipped computer or 
workstation often is effectively his or her own system 
administrator, a role that often consumes excessive 
resources due to lack of expertise. It is expected to be a great 
advantage to eliminate this problem by effectively offloading 
the problem to a small number of server administration 
experts, rather than having many users struggle with the 
problems of software installation, upgrades and computer 
administration. 

As mentioned above, this vision of the future of personal 
computing is presently in its infancy. As a result, there are 
presently many problems and deficiencies with existing 
systems. 

Typically, in network computer systems, an administrator 
creates user profiles that are stored on a network server. The 
profiles may contain different types of information, such as 
user desktop preferences and user permissions for access to 
different software applications that might reside on the 
server. When a user logs onto the system, the user identifies 
him or herself to the server, the server locates the profile for 
the user and transmits it to the user computer where it is used 
to configure the computer and generate a desktop. The 
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desktop might include a number of icons representing appli- 
cations to which the user presumably has access. The profile 
likely also contains other attributes of the computer and 
desktop, such as for example, the background color of the 
5 desktop, or character fonts and point sizes used on the 
desktop, or data file search paths, etc. that are unique to the 
user. The profiles may be user modifiable or non-modifiable. 

In an environment in which users can modify their own 
profiles, a modified profile rs uploaded back to the server at 

10 log-off time, where it is stored for retrieval the next time the 
user logs-on. In some prior art systems, to the best of our 
knowledge, the users can generate on their desktops any 
configuration of application icons they wish, whether or not 
they exist on the server, and whether or not a user actually 

1S has access permission to an application on the server. The 
Lotus Workplace Desktop (previously called Kona Desktop) 
system is an example of this type of operation. In other 
systems, the server presents a list to the user of all applica- 
tions that the server has, from which the user can pick. In this 

20 case, there is no guarantee that the user actually has access 
permission to an application that is selected from the list for 
inclusion on the desktop. The Sun Hot Java Mews system is 
an example of this type of system. In other words, the prior 
art systems do not correlate between what the user can 

25 configure for the set of desktop application icons and 
applications to which the user actually has permission 
access. In such a case, when the user clicks on a icon to 
execute an application, an error message may occur (such as 
an unauthorized access message) if access permission is not 

3Q present, or in a worse case, the user's computer may crash. 
Another limitation with existing art is that a flat data 
structure is used to model users, user groups, terminals and 
groups of terminals. Modeled after a common scheme for 
managing user access to computer resources, known net- 

35 work computer implementations (e.g., Lotus Administration 
Facility for Desktops, Microsoft Windows NT Profiles and 
Policies, and Sun Hot Java Mews) implement a flat "groups** 
structure on the server for managing software preferences 
(or attributes) in various contexts. A "context", as used here, 

40 refers to an individual user, user group, terminal, or terminal 
group. Any grouping structure for managing software pref- 
erences on the server allows an administrator to define 
preference attributes for different groups of users as well as 
for individual users. However, flat systems are inflexible in 

45 many environments, especially in environments having 
large numbers of users. It is desirable to provide an admin- 
istrative tool supporting the organization of preference infor- 
mation into a hierarchical structure. 

Another limitation with existing systems is that they are 

50 limited in the ways that administrators and users have to 
perform user configuration of workstation desktops. For 
example, administrators are presently required to configure 
user preferences using configuration programs that are sepa- 
rate from, but associated with, a user application. It is 

ss desirable to allow vendors to provide only a single applica- 
tion. To require only an end user application from a vendor 
necessitates that the central management facility be able to 
execute the end user application in a context of a user or user 
group. The prior art does not allow this administrative 

60 flexibility of operation. In other words, in the prior art, to the 
best of our knowledge, an administrator does not have the 
ability to run a user application in the context of a user to set 
preferences for that user and application. Further, in the art, 
an administrator cannot run a user application to set pref- 

65 erences in the context of a group of users. 

Still another limitation in the prior art known to the 
inventors is the manner in which the prior art partitions 
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server permanent storage space to guarantee that a unique istrator changes the context that the application is running 
space is reserved for storing user preferences related to the under, the application needs to be relaunched to load con- 
different applications on the server. To the knowledge of the figuration information for the new context The process of 
inventors, the problem of preventing collisions in the storage relaunching software each time a context is changed is time 
of preference information for different applications in 5 consuming and inconvenient for an administrator, especially 
object-oriented systems, in which an object can be queried ^ systems with many users. In such systems, it is expected 
for its fully qualified class name which uniquely identifies ma t an administrator will change contexts many times while 
and differentiates it from other classes, is solved by having configuring an application, 
a first central authority assign a unique desi^ation" that 

applies to a vendor and by then having a second authority at 10 SUMMARY OF THE INVENTION 

the vendor assign a second designation relative to the first ~ . , , , . . , 

. . .. r u j r.-r i The system described herein provides a common reposi- 

designation for each vendor application. For example, ven- . c * *- - c *• r j i * • 

, * • . 4 . , . - t - j a *l c. tory for configuration information for users and applets in a 

dorA might be assigned the designation vendorA by the first to . 4 ™. . - , 4 t "*\ ct 

ep7 &" j . chent-server environment This is referred to as client profile 

authority and that designation is guaranteed to be unique . ~. „ . *u * • • 

%u* .£ u% *, c u- u «u * * .u * management. The system allows users to roam, that is, to 

within the architecture for which the first authority is acting. 1S , • r , - 4 . 4 . ,7 

™ » i • j * *t_ 6 , lb log-in from any computer in the system at any tune and have 

The second authority at vendor A then assigns the second « a • *: n . *: -j- * 

, . . - . r -.l^Tl ^ configured automatically at run time according to the 

designation for each of its applications within that architec- r „ „ . j r ,u **u f , 

_ ^V, . r . a, i- . , . preferences stored for the user at the server. The preferred 

hire. For example, one of vendor As applications might be u j- * - t /t * ^ , , f 0 r T x 

. . . . j a a * ... , j • * j embodiment is a Java (Java is a Trademark of Sun, Inc.) 

designated-vendorA. Appl : another might be designated , , j «i_ i- . * , , 7 

Jr * a rr. Y t . • . ■ r based system and the client computers use a web browser 

vendorAAppZ. Ine art maps the unique designation for 9 n • . j . * T t • «• . 4l _ 

, T\. . , , i - interface arranged to execute Java applications. Thus, in the 

each application in a system to a location in permanent c j , , - . « % • * « . 4 

rr - . , A J .... <• « , c preferred embodiment, user applets and the desktop applet 

storage of the system to guarantee that preference data for „ , » , T , 4 TI .. - * • * j j 

At _ * . A a are assumed to be Java applets. However, it is not intended 

the different applications do not collide in storage. An . .... . T • * ^ _ r r 

.. . rr ... A . b to limit the invention to a Java environment. Preferences for 

appbcaton, when nmning, .nforms the netwoA computer ^ locaU ^ mi ^ t ^ ltaml locally m 

server of its unique storage location and it is the responsi- 9 c t _ , , ... r r 4l _ ' , , 

, fi , n ^ "P. , . . , r . ^ traditional manner, while preferences for the server-based 

bility of the server to partition an area at the starting location , 4 • . . . . ji j - , , 

_j- * _f / * * i . 1 applets might be handled m the way described herein, 

according to a context (user, user group, terminal or terminal J 

group) for storing preference information so as not to collide ^ mventl ° n automatically determines a unique storage 

with preference information in a different context Clearly, locatlon for storin S Preference information for an object- 

this manner of administering storage space is awkward and 30 onented application, without resorting to the requirement of 

undesirable. It is desirable to devise a method to automati- having a central authority assign a unique designation for the 

cally generate unique storage locations for storing prefer- application and without requiring the coding of storage 

ence information for the afore mentioned object-oriented location information into the application. 

applications, without resorting to the requirement of having I° *h e preferred embodiment, the system comprises a 

central authorities assign unique designations for the pur- 35 network which interconnects a server and a plurality of user 

pose of preventing collisions in the storage of preference stations. The server stores a plurality of object-oriented end 

information and without coding storage location information user applications for downloading to user stations and it 

into an application. further stores configuration preferences for the end user 

Still another limitation in the art lies in the lack of any applications in the context of different groups and users. A 
provision to migrate existing applications and hardware into 40 profile manager is provided at an administrators station. The 
the new environment of the centrally managed network P rofile manager ^ arranged to execute a configuration 
computing world without requiring changes to the existing application for an end user application, whereby the admin- 
hardware and applications. Existing hardware, a terminal for istrator can specify configuration preferences for the end 
example, in a networked environment, gets its configuration uscr application in the context of different groups and system 
information at boot-up time from a file in a specific format 45 users - When a of configuration preferences is to be saved 
located on a server. The terminal is programmed to know OQ ^ XIVcr > a unic l ue location on the server for storing the 
how to access its configuration file. The terminal uses a configuration preferences is determined for the end user 
unique identifier to access the file from the server. The application in a selected context by retrieving the fully 
unique identifier is often the media access control (MAC) qualified class name of the end user application from an 
address of the terminal. However, in a new centrally man- 50 on ^ c administrator's station which represents the 
aged environment involving protocols and API's that are configuration application. The fully qualified class name 
different from that to which the terminal is designed, the uniquely identifies and differentiates the class from other 
terminal cannot access preference information in the new classes. The fully qualified class name is combined with the 
environment, the terminal can only access its configuration selected context to form a key. The key is then mapped in a 
file in the way for which it is designed. This is a serious 55 Prescribed manner to generate the unique storage location 
problem, because there are many such existing devices in address for the application and context 
use. The inability to use them in new systems impedes BRIEF DESCRIPTION OF THE DRAWING 
substantially the incentives for users to migrate to the new 
systems. In the Drawing, 

Still another limitation in the prior art concerns the 60 FIG. 1 shows an illustrative network and user stations, 

interface between an administrator and the configuration including an administrator's station, in which the invention 

management system. When configuring software within an might be practiced; 

administration facility to configure preference information FIG. 2 shows an illustrative block diagram form of the 

for various users and user groups, and terminals and terminal administrator's station in communication with a server, and 

groups, the administration software launches in the context 65 components of the administrator's station and the server for 

(user, user group, terminal or terminal group) set by the providing the central profile management and preference 

Administrator who is running the facility. When the Admin- administration; 
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FIG. 3 shows one illustrative hierarchical organization of 
user groups and users of a system. The illustrative hierar- 
chical organization might also contain individual terminals 
and terminal groups; however, these are omitted for sim- 
plicity; 

FIG. 4 shows one illustrative listing of individual users 
and the group priority order that is used to determine a set 
of preferences -from -the -hie rarchical- organization-of-FlG. 3 
that apply to a user and a specific application executed by the 
user, 

FIG. 5 shows a more detailed view of the administrator's 
station and server of FIG. 2; 

FIG. 6 shows an illustrative view of the software objects 
at a user's terminal, including a user application and the API 
between the application and other components, that coop- 
erate to establish the user preferences during execution of 
the application as the user's terminal; 

FIGS. 7 through 8 show illustrative operations at both a 
user's terminal and a server for user log-on and initially 
establishing the user's desktop, including desktop 
preferences, at the user terminal; 

FIGS. 9 through 11 show illustrative operations at both an 
administrator's terminal and a server for administrator user 
log-on, establishment of the administrator's desktop, and, by 25 
way of example, the selection of an application and a context 
for configuration; the example also illustrates a context 
change during configuration the user's desktop and the 
resulting operations; and 

FIGS. 12 through 24 show a variety of actual admin is- 30 
trator screen snapshots in various phases of application 
administration, including building of a hierarchy of which 
FIG. 3 is a representation of an example of, the creation and 
deletion of users, etc. the establishment of application pref- 
erences for applications, and context changes during pref- 
erence establishment 

DETAILED DESCRIPTION 

The system described herein provides a common reposi- ^ 
tory for configuration information for all users and applets in 
a client-server environment. This is referred to as client 
profile management. The system allows users to roam, that 
is, to log-in from any computer in the system at any time and 
have it configured automatically at run time according to the 45 
preferences stored at the server. The preferred embodiment 
is a Java (Java is a Trademark of Sun, Inc.) based system and 
the client computers use a web browser interface arranged to 
execute Java programs. 

The terms "applet" and "servlet" are established terms in 
the Java programming language art and will be used herein, 
since the terms have meaning to those skilled in this art 
"Applet" refers to an independent software module that runs 
within a Java enabled web browser. Servlet refers to a 
software module that resides on a Java enabled web server. 
It is to be understood that the use of the terms "applet" and 
"servlet" herein is not intended to limit the invention in any 
way. For clarification, the phrase "configuration applet" is 
used herein to refer to a software module used to configure 



environment The invention can be used in any client-server 
system. For example, if desired, the system could be 
designed to use proprietary communication protocols and 
applications written and compiled in any desired program- 
ming language. Further, even in the preferred Java based 
environment, disk-based computers might access some 
applications locally, and other applets from the server. 
Preferences_fpr the locally stored applications might be 
stored locally in the traditional manner, while preferences 
for the server-based applets might be handled in the way 
described herein. Preferably, however, preferences for 
locally stored applications are stored on the server using the 
Profile Management Properties API in addition to the pref- 
erences for server based applets described herein. 

A simple Application Program Interface (API) allows 
applets written to the API to easily store and retrieve 
preference data when the applet is executed by a user or 
administrator. Applet permissions and user preferences can 
be defined based on group memberships and individual 
20 identity. 

Client profile management includes the following services: 
Log-on support — mapping to a user profile; 
User support — the administrative ability to create user 
identifications and provide services and preferences 
directly to users; 
User groups support — the administrative ability to create 
hierarchical groups of users and provide services and 
preferences based on group memberships; 
User applet context transparency — automatic determina- 
tion of the context of user applet execution. That is, the 
determination of the user and/or group profiles that 
apply to a user applet execution and the automatic 
establishment of the profile environment; 
User applet preferences repository— -context-sensitive 

server storage for user applet configuration data; 
Dynamic user applet preferences inheritance — 
hierarchical load-time coalescence of user applet pref- 
erences via the object-oriented principal of inheritance; 
and 

User applet access control — control of user applet execu- 
tion based on group default membership privileges. 
The administrator can override default group privileges 
and permit or deny additional access privileges for 
individual users. 
Profile management provides a framework through which 
these tasks are performed. Some tasks are supported by 
profile management directly, e.g. user/group management, 
applet lists, context switching, preference inheritance, etc., 
while configuration services specific to user applets are 
usually supported by separate configuration applets invoked 
by a system administrator within the client profile manage- 
ment environment. Some end user applets might provide the 
configuration capability as part of the end user applet If this 
is the case, the administrator can run the end user applet (as 
opposed to a separate configuration applet) in the context of 
individual users and groups to set the configuration prefer- 
ences for those users and groups. 

FIG. 1 shows one high level view of an intended envi- 
p references for an end user software application such as a $o ronment for practicing the invention. A network 100 is 
word processor, a database manager, etc. Since software provided for interconnecting a plurality of user stations, 
applications are also "applets" in the Java environment, the such as desktop personal computers 102, mobile laptop 
phrase "user applet" or just "applet" is used herein to refer computers 104, workstations 106 (e.g., RISC computers), an 
to an end user application. administrator's station 108 and a server 110. In one 

In the preferred embodiment, user applets and the desktop 65 embodiment, network 100 might be a local area network. In 
applet are assumed to be Java applets. However, it is another embodiment, network 100 might include wide area 
understood that the invention is not limited to a Java networking for entities such as corporations that have geo- 
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graphically displaced sites that are still included within the and groups. The ProfileManagementProperties object class 

system. There is do intent to limit the environment in which provides all of the functionality of the java.util.properties 

the invention might be practiced; indeed, a network of any class with the further ability to provide create, save, and 

type that interconnects many types of stations is envisioned. retrieve the configuration information for software from 

A high-level diagram of the profile management admin- 5 permanent storage. Storing such information in a central 

istrative operating environment is shown in FIG. 2. An location makes management of user and group configura- 

administrator client network computer 200 is represented on dons possible. When a user is in the role of administrator, 
the.left of the Fig. and a server 202 for the system is on the_ ProfileManagementProperties 210 allows the administrator 

right. The client and server communicate via a network to configure the user applet corresponding to configuration 

represented as 203. The particular example of FIG. 2 10 appletl, or to configure appletl if appletl is an end user 

assumes that the client computer is a system administrator's applet, and store the configuration information in the proper 

computer. place on the server in the proper context. This allows the 

Profile manager 206 on the client side allows the admin- establishment of a relationship between the user applet and 

istrator to configure user applet preferences at both user and the user, rather than between user applet and computer as in 

group levels. The administrator can create new users and is traditional systems. ProfileManagementProperties 210 is an 

group hierarchies, add users to different groups, specify extension of the java.util. Properties class. The extension 

applet permissions for each group and for individual users. allows the key/value pairs of preference information of a 

And the administrator can configure applets in the context of Properties object to be associated with a key, as opposed to 

an individual user or a group. The administrator can add, a stream, as with java.util .Properties. This, in turn, allows 

delete and reset passwords for users. Profile management 20 application developers to use the key to specify a unique 

support is transparent to the general user. The administrator location relative to a context for preference information, 

can invoke the profile manager 206 in the context of any user rather than a file name and path. ProfileManagementProp- 

or group. Only the administrator can change from his/her erties 210 determines the key automatically. The generation 

context to administer clients (users) and groups. The server of the key is discussed more in connection with FIGS. 8 and 

will not allow a user without administrative authority to 25 9. By modeling ProfileManagementProperties 210 after the 

switch context. When a request comes into the server, it will java.util .Properties class, the system can take advantage of 

query the authenticated ID of the user trying to access this preference inheritance through recursive class-default evalu- 

function. If the user does not possess administrative ation. Thus, this extended class provides a "group default" 

authority, (i.e., is not a member of the All Use rs .Adminis- capability by accumulating preferences starting at a current 

trator group), the Profile Manager Servlet 214 will reject the 30 context, as discussed with respect to FIG. 3, and traversing 

request. up the contextual hierarchy for defaults. 

Profile manager 206 invokes other applets, such as Server 202 includes a database 212 that stores user data 
appletl (208), as shown in FIG. 2. In this example, appletl and group data, such as user and group preferences and user 
might be the administrative applet for configuring prefer- applet access permissions. Webserver 218 represents a typi- 
ences related to user desktops. Or appletl could be a 35 cal web server with support for Java applets. Profile Man- 
configuration utility related to an end user applet, such as ager servlet 214 maps user and group identifications to 
editors, word processors, databases, etc. It is preferred, but preference data. It also maintains an access control list to 
not required, that configuration applets such as 208 exist as manage user access to applications on the server, 
modules separate from their corresponding user applets. In User and group preferences are stored as a tree hierarchy, 
the context of FIG. 2, Appletl is typically a configuration 40 as shown in FIG. 3. All users of the system automatically 
applet for a user applet; the administrator runs the configu- belong to the top group AllUsers. All users belong to the 
ration applet appletl under a group context to set group AllUsers group; this group contains the default preferences 
preference and permission defaults, or in a user context to for some or all user applets on the server. In FIG. 3, it is 
customize user applet configurations for an individual. By assumed that the server contains at least three user applets, 
implementing appletl as a module separate from its user 45 identified as App3, App4 and App5. As indicated in the 
applet, performance is enhanced; since the configuration AllUsers group, the default background (BG) for App3 is 
appletl will likely be small compared to the user applet. BG=blue. Other illustrative preferences labeled as x, y and 
Also, separate configuration applets allow the administrator z are shown to have the default values of 1, 2 and 3 
to control the end users ability to configure the user applet respectively. The terms x, y and z are intended to represent 

Traditional stand-alone computers store user applet con- so any desired preference and the values 1, 2 and 3 are arbitrary 

figuration information locally in association with its the user and used merely to illustrate the point The x preference 

applet. Traditional stand-alone Java based computers store might for example be the screen font for the desktop; the 

user applet configuration information using the format pro- value x=l might call for a default font of limes-Roman, 

vided by the java.util.properties class. Both arrangements Similarly, the default preferences for App4 for all users are 

require that the user applet specify the name of a local file 55 BG-gray, x-2, y-2 and z-2. 

in which to store configuration information related to the Hie default values in the AllUsers group can be modified 

user applet In other words, a relationship is required in any desired way for other contexts, such as for other user 

between the computer and the user applet loaded on it groups and individual users. By way of example, in addition 

Profile management as described herein provides the famil- to the context of AllUsers in FIG. 3, four other groups 

iar capabilities of a real java.util.properties object phis 60 (Group X, Group Y, GroupYl and Group Y2) are shown, 

additional facilities supporting user-roaming capabilities Additionally, two individuals Userl and UserN are shown, 

and seamless pluggabitity into a powerful administrative Users can be members of more than one group. In FIG. 3, 

framework (the Profile Manager). Userl is a member of AllUsers, GroupX and GroupYl; 

ProfileManagementProperties P210 is a properties object UsenN is a member of AllUsers and GroupY2. If a user is 

for appletl and provides an API between Appletl and the 65 a member of more than one group (another group in addition 

server that allows the server to determine where to store to AllUsers), then the groups are prioritized for the purpose 

configuration information for appletl in the context of users of selecting the preferences for a given applet for that user. 
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The administrator configures the group priorities for a user. FIG. 4 shows that the highest priority group for Userl is 

Group priority is illustrated in FIG. 4. In FIG. 4, Userl has AllUsers.GroupX; this branch of the group hierarchy will be 

GroupX (identified by the fully qualified name of AllUsers- checked first for preference information pertaining to App3. 

.GroupX for his or her highest priority group. Userl 's next From here on, the example is essentially the same as 

highest priority group is GroupYl 5 example 1 above, except that the coalesced set of prefer- 

(AllUsers.GroupY.GroupYl). Userl's lowest priority group ences is used to configure App3 on the user's workstation, 

is the AllUsers group. When a user, say Userl, requests to The preferences for App3 for Userl are: BG=Green, x=l, 

run an applet say App3, the preferences are coal esced from y=2, z=»3 since the BG=Green preference stored in the 

the tree of FIG. 3 according to the group or groups to which Userl's context for App3 over rides the default BG=Blue 

the user belongs and the user applet is configured on the user 10 preference obtained from the AllUsers.GroupX branch of 

desktop accordingly. the preference tree. 

The first step in coalescing preferences for any context is Example 3: Coalescing preferences for com.ibm.App6 in 

to get the defaults. The defaults for a user, if there are any, the context of Userl. 

is the coalesced set of preferences for the applet from the This example illustrates the situation of the highest pri- 
highest priority group from which preference information is ority group containing no coalesed preferences for the 
for the applet can be obtained. The defaults for a group, if context of Userl. Again, the highest priority group for Userl 
there are any, is the coalesced set of preferences for the is GroupX. This group and its parent AllUsers contain no 
applet from the groups parent (i.e., The AllUsers group is the preferences for App6. Therefore, the next highest priority 
parent of AllUsers.GroupX). If a group has no parent (i.e., group is searched. The next highest priority group for Userl 
the top level AllUsers group), there are no defaults for that 20 is GroupYl. A set of preferences can be obtained from this 
group. To coalesce the preferences for an applet at a context, group for App6. The coalescence of preferences proceeds as 
the preferences for the applet explicitly stored at the context, described in example 1. Recursive calls are made from 
overwrite the default preferences for the applet for the GroupYl up the tree to the root AllUsers group and the 
context Thus, to coalesce preferences into the default set for preference sets are returned back down the recursive calls 
an applet in a group context, recursive calls are made from 25 and modified along the way to form the default set. The 
each group node up to the AllUsers group requesting each default set is then modified with the preferences stored in 
parents set of preferences for the applet. Please refer to FIG. GroupYl to form the coalesced set of preferences that apply 
3 to illustrate the following example. For example, if the to this context. Stated briefly, Allusers returns a null set of 
context is Alhjsers.GroupY.GroupYl, a call is made to the preferences, since it has no preferences for App6. GroupY 
parent of GroupYl, which is GroupY, requesting its default 30 modifies this null set with the values a=l arid b=2 and 
preferences for the applet GroupYl makes a recursive call returns this set to GroupYl as the default set GroupYl 
to its parent, which is AllUsers. AllUsers has no parent, so modifies the default set with a=33. This set is returned to the 
AllUsers returns it set of preferences for the applet to the call Userl context for use as its default set. Since there are no 
from GroupY This set of preferences is modified by the preferences for App6 stored at the Userl context, the 
preferences stored in GroupY for the applet, if any. This is 35 defaults obtained from the GroupYl branch of the prefer- 
now the default set of preferences for the applet for the ence tree represent the fully coalesced set of preferences for 
context of GroupYl. This set of default preferences is App6. The real set of preferences thus becomes a-33, b»2 
returned to GroupYl as a result of the recursive call from for this context. 

GroupYl to GroupY, and are modified by the preferences at The above 3 examples described the gathering of prefer- 

GroupYl for the applet, if any, to become the actual set of 40 ences in response to a load( ) for a particular piece of 

preferences to be used in this instance. The set of preferences software. When preference information is saved for a piece 

for the context of a user is built in the same way, except that of software, any preferences that have been explicitly writ- 

the highest priority group from which preference informa- ten at the Context being saved to will be written to the data 

tion can be obtained for the user is used to first establish the store (212) at the location specified by the combination of 

group context from which the defaults will be obtained. 45 the Context the software is being run in and the key for the 

Then the recursive procedure described above is used to software whose preferences are being stored 

build the actual set of preferences for the user and the applet Permissions operate similarly: a new group has access to 

requested by the user. all the applet names permitted by the group itself as well as 

The following examples illustrate the above preference to all applets permitted by its supergroups. However, just as 

coalescence and should be read in conjunction with FIG. 3. 50 Java allows the programmer to override a superclass 

Example 1: An administrator runs a configuration applet method, Profile Management allows the System Adminis- 

for App3 to set preferences for the group AllUsers.GroupX. trator the ability to override an inherited permission. This is 

To set the preferences for App3 in the context of called overriding a permission. 
AllUsers.GroupX, the present set of preferences must be As with Java's form of inheritance, Profile Management's 
determined. AllUsers.GroupX requests defaults for its par- 55 form of preferences and permissions inheritance is called 
ent AllUsers. Since AllUsers is the top level group, it returns single inheritance. Single inheritance means that each Pro- 
its preferences for App3 to GroupX. These are the default file Management group can have only one supergroup 
preferences for App3 in the context of GroupX. Since (although any given supergroup can have multiple 
GroupX has no preferences for App3, the default set from subgroups). 

Allusers is the real set of preferences to be used. In this 60 Profile Management users (leaf nodes) may require mem- 
example, these preferences from the AllUsers group are: bership in multiple groups, so a facility is required to limit 
BG=Bhie, x=l, y=2, z=3. The administrator can now modify preference inheritance to a single hierarchical group to 
use the configuration applet to modify the coalesced pref- minimize the chance of corrupt configurations due to the 
erences in any desired manner. introduction of incompatible variable subsets introduced by 
Example 2: Userl requests execution of com.ibm.App3. 65 cross group branch coalescing. By allowing a user's group 
Preferences must be coalesced for com.ibm.App3 in the memberships to be prioritized, profile management can 
context of Userl. follow a search order when looking for preferences related 
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to a particular applet. In other words, starting with the group 
with the highest priority, the search will stop at the first 
group fouod to contain configuration data for the applet 
attempting to load its preferences. 

A user inherits software permissions from group mem- 5 
berships. With careful enterprise modeling, the administra- 
tor can assign software access to many users without having 
to navigate through panels, one user at a time. Profile 
management controls access by programming the web 
server to permit/deny access to applets. The web server 10 
enforces the access control The profile manager servlet is 
also protected by the Webserver requiring user ID's and 
passwords to be passed to the webserver for authentication 
purposes. It is standard browser functionality to prompt for 
user passwords as required. is 

FIG. 5 shows the system of FIG. 2 in more detail. 
Configuration applet Appletl is invoked by the administra- 
tor within the profile management framework. Appletl may 
implement the application program interface (API) 515 for 
querying information about its operational environment 20 
(e.g., query context, context changed events, query access 
control list for this context, etc.) to integrate tightly within 
the profile management framework, but this is not a require- 
ment for a configuration applet. In any event, the designer of 
appletl need only understand the basic API methods: 25 
enablePersistence( ), load( ), and save( ) in addition to the 
basic methods of a java.util. Properties object used to get 
preference information into and out of a j a va.util. Properties 
object. API 515 additionally provides list( ) and getcontext( ) 
methods. Appletl need only register with the ProfileMan- 30 
agementProperties class and call these methods as appro- 
priate. The load( ) method can be called to retrieve the 
present state of preferences for the user applet being con- 
figured in the context of a user or group selected by the 
administrator The administrator can then modify the pref- 35 
erences as desired and store them using the configuration 
save functionality provided by the applet (which uses the 
save( ) method of its ProfileManagementProperties object. 
Similarly, if appletl needs the list of user applets authorized 
for access by a user, it can use the list( ) method to obtain 40 
the list from the server. The getcontext( ) method can be used 
by the applet to display the name of the context that it is 
running in or even to ensure that it only runs in a certain 
context (i.e., if an applet wanted to configure a service on the 
server using the export agent, it might only allow itself to be 45 
run at the AllUsers context since the configuration being 
exported is server specific as opposed to user specific. For 
appletl to run in the profile management framework, all that 
is required is for the applet to register with ProfileManage- 
mentProperties 410 and implement the Profile Management- 50 
Properties class, an extension of the java.u til. Properties 
class. 

The profile manager 506 also provides a context change 
API 516 for configuration applets. Appletl may implement 
a context change event listener 512. The API 516 and the 55 
event listener 512 allows the administrator to change con- 
texts (user or group) while running the configuration applet, 
without having to stop and restart it For example, when 
configuring applet user preferences, the administrator will 
likely change contexts many times during the configuration. 60 
If the configuration applet is registered as a listener to such 
events, profile manager 506 will notify it of a context change 
via API 516. This allows appletl to refresh its preferences 
from the server for each new context. Without the event 
listener API, appletl would have to be terminated by the 65 
administrator and restarted after a new context has been 
selected to reference the existing preference information for 
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the new context and avoid being stopped and restarted by the 
Profile Management applet To register, appletl calls a 
method on its properties object ProfileManagementProper- 
ties 510 i.e., addContextCbangeListener (API 516) to reg- 
ister itself. When the administrator sets a new context, 
profile manager 506 performs a set context call (API 516) to 
object 510, which in response calls the reload method (API 
516) on event listener 512. Event listener 512 now performs 
a load proper ties cailto its - properties' object 510 to gel* the - 
new preference data from the server for the new context, and 
causes appletl to updates it GUI and internal variables to 
reflect the new preference information. 

The above functionality avoids the possibility of a net- 
work administrator reading data from one context, changing 
context, and accidentally overwriting with a save( ) wben 
intending to load( ) before making configuration changes in 
the new context. 

Applets that do not register as listeners will be stopped, 
destroyed, reloaded, and restarted by the profile manager 
applet when the administrator forces a context change. 

The profile management also provides a "properties 
export" service to allow the easy retrofitting of existing 
hardware and software into this profile management envi- 
ronment. The properties export service allows profile man- 
ager 514 to support user workstations (the physical 
hardware) as well as users, groups, and user applications. 
Since existing workstations do not know about ProfileMan- 
agementProperties 510, the export service allows worksta- 
tion vendors to create workstation-configuration applets that 
specifies an export agent 520 to be invoked on the server 
when the vendor applet saves it preference information. The 
export tag causes an instance of a vendor-supplied class (the 
export agent 520 object) to be created and the export method 
to be invoked on the object to specify that workstation 
configuration information be saved in whatever proprietary 
file format and/file location(s) that are required by the 
workstation being configured. 

Assume that appletl is the configuration applet provided 
by a vendor for an existing terminal that is incompatible with 
the present profile management system. The vendor also 
supplies export agent 520. An administrator can configure 
the terminal for operation in this system by running profile 
manager 506, set the context to the terminal being 
configured, runs the vendor supplied configuration appletl 
and configures the applet Wben the administrator saves the 
configuration, part of the information that is transmitted to 
the server is a unique identifier that identifies the tenninal 
being configured. Typically, this is the Media Access Control 
(MAC) address of the terminal. Profile manager servlet 514 
detects that an export agent is specified on the save. Profile 
manager servlet 514 detects this from one of the preferences 
being saved that specifies need for the export agent. The 
preference specifies the export tag in the form of a key value 
pair of 

XXXXEXPORT_AGENTXXXX-{fully qualified class 
name of export agent} 

The Export Agent's export(Context context, config 
properties) method is called by the profile manager servlet 
514 to create one or more files 522 on the server from the 
save preferences information. The specific file or files are 
identified by the unique identifier of the terminal that came 
with the properties information from appletl. When the 
terminal later boots up, it uses its unique identifier to locate 
and retrieve its configuration information from files 522 on 
the server in the same manner that it always did, independent 
of the profile management system. 

FIG. 6 illustrates an applet2 running on a client computer. 
Applet2 might be an end-user applet such as a word pro- 
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cessor. Id any event, applel2 has access to some of the the 
same API methods as shown at 515 of FIG. 5 if it desires. 
Applet2 uses the load method to retrieve preferences and the 
save method to save any preferences that might be changed 
by the end user. Enable Persistence initializes the Profile 
Management Properties object for applet2 with context 
equal to the user and generates the unique key for identifying 
the preference i nform ation storage loc ation on the server, as 
described above relative to the administrator. 

FIG. 7 shows the situation of a user bringing up his or her 
desktop. The user on the client (700) points his or her web 
browser at the URL of the desktop applet on the server and 
at step 704 sends a message http://server/Desktop.html). 
Since Desktop.html is a file that the server protects, a 
challenge is sent back to the web browser on the client at 
706. The web browser on the client responds by prompting 
the user for a user ID and password. The client then sends 
the user ID and password information to the server at 708. 
The user ID and password are shown in bold at 708 of FIG. 
3 to illustrate that this information is passed by the web 
browser itself. This type of nomenclature is used in other 
places to illustrate the same thing. Since, presumably, the 
user has permission to run the desktop applet, the request 
will be honored. 

There are a series of interactions between the client and 
the server (not shown) where the code for the desktop applet 
is loaded to the client from the server. The desktop object is 
created and begins to execute at 712. The desktop object 
needs its preference information (i.e., configuration 
information) so it can tailor the desktop for the end user who 
is invoking it. To this end, as part of the desktop object's 
initialization process, the desktop creates a ProfileManage- 
mentProperties object P at 714, which is used to load, get, 
cache, set, and save a copy of the user's preference infor- 
mation from the server for the desktop applet. The desktop 
object then performs an API call P.enablePersistence 
(desktopObject (applet)) at 716, which, at step 1) of 716, 
initializes the ProfileManagementProperties object P with 
the URL of the profile manager servlet 214. This URL is 
derived from the URL of the desktop applet that was loaded 
from the server previously. The ProfileManagementProper- 
ties object P sends a request 718 to the profile manager 
servlet 214 to get the context for the user running the 
desktop applet. In this case, the context consists of two 
components, a context name which is the ID of the user, and 
a context type which in this case is User. The profile 
manager servlet gets the ED of the user from the request 718 
and returns the user context at 719. At step 2 of 716, the 
ProfileManagementProperties object P is initialized with the 
context of the user running the desktop. At step 3 of 716, the 
ProfileManagementProperties object P generates a unique 
key for the desktop software by asking the Java desktop 
object P for its fully qualified class name. All Java objects 
know their class name. This unique key is combined with the 
user's context information to provide a parameter that 
specifies a unique location in the database 212 for storing the 
user specific preference information for the desktop applet. 
Any desired method can be used for mapping the string 
consisting of the fully qualified class name and the user 
context information into the data store location. Next, a 
request 720 is sent to the profile manager servlet 214 to get 
the preference information, tailored for the user, for the 
Desktop applet. The context and key are passed as part of the 
request 720 to identify the requested preference information. 
The profile manager servlet 214 responds with the requested 
preference information at 722, which is cached in the 
ProfileManagementProperties object P 604. 
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Continuing on at FIG. 8, at 800 the Desktop object reads 
it's preference information out of its ProfileManagement- 
Properties object P, and begins to update the desktop accord- 
ingly (i.e., it might set the screen color to blue, get infor- 

5 mation about the position of icons, etc.). The desktop object 
calls a method on its ProfileManagementProperties object P 
to get a list of the software to which the user has access 
permissio n. The ProfileManagmentPrope rties ob j ect P 
requests the information at 802 from the profile manager 

10 servlet 214, which generates a response with the requested 
information at 804. For each such applet to which the user 
has access, the information includes a user friendly name, 
the applet's URL, the URL of an icon for the applet, etc. 
(information that is required for the desktop to represent the 

15 applet on the desktop and to load and launch it), and other 
optional material which is not relevant to the invention. This 
information is stored in the ProfileManagmentProperties 
object P, and returned to the desktop object At 806, the 
desktop object uses the applet information to build a folder 

20 for the applets and to generate a window displaying the icons 
and the user friendly name for each applet to which the user 
has access. 

Assume that in a previous run of the desktop by the user, 
the user dragged and dropped the icons for some of the 

25 software displayed in the folder that was just described. It is 
possible that at this time the user no longer has access to the 
applets that were dragged and dropped from the folder to the 
desktop. However, these desktop objects normally would be 
a part of the users preferences that were saved during the last 

30 run and would still be displayed on the desktop. To avoid 
this situation, the desktop examines its preferences from it's 
ProfileManagmentProperties object P to check for applets 
that are configured to appear outside of the window that is 
generated to display all applets to which the user has access. 

35 FIG. 8 assumes that there is only one applet outside of the 
applet window that is generated. If there were more than one 
such applet outside of the applet window, the following 
procedure would be looped for each such applet. At step 810 
the desktop checks each of these applets appearing outside 

40 of the applet window against the list of applets from the 
server to which the user has access. If the applet appears in 
the list, the icon for the applet is placed on the desktop at 810 
in the same position as before. If the user no longer has 
access to the applet, the applet is removed from the desk- 

45 top's preferences at step 814 and removed from the Profile- 
ManagmentProperties object P. If any applets are removed 
as part of this process, the desktop tells the ProfileManag- 
mentProperties object P to save the preferences at step 816. 
The ProfileManagmentProperties object P sends a request 

50 818 with the preference, key, and context information to the 
profile manager servlet 214 to save the new preferences 
information in the Database 212. The server sends a 
response 820 to the ProfileManagmentProperties object P 
informing the ProfileManagmentProperties object P that the 

55 request was successfully completed. 

FIG. 9 illustrates the situation of an administrator running 
a configuration applet to configure preferences for an applet 
for other users or groups of users. It is understood that the 
principles discussed here also apply generally to the con- 

60 figuration of terminals or groups of terminals. The admin- 
istrator on the client 900 points his or her web browser to the 
URL of the profile manager applet 214 on the server, which 
is to be run. The URL is sent to the server at 904. Since 
ProfileManager.html is a file that the server protects, a 

65 challenge 906 is sent back to the web browser on the client. 
The web browser responds by prompting the administrator 
for a user ID and password. The request to get ProfileMan- 
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ager.html is then repeated at 908 to the server with the user Operation continues at FIG. 10. The profile manager 

ID and password information included in the message. Since requests the information about existing users, user groups, 

presumably the administrator has permission to run the and software from the profile manager servlet 214 and builds 

profile manager, the request is honored and a profile man- the tree in the left panel of the profile managers configura- 

ager applet is downloaded to the administrators terminal at 5 tion window at 1002. See FIGS. 13 through 24 for examples 

910. There are a series of interactions between the client and of me administrator's left panel. At this point 1004, the 

the server (not shown) where the code for the profile administrator selects a desired context for configuring by 

manager applet is loaded to the client from the server. The cUckm OQ a usef or fa)m me kft - ^ ^ 

profile manager object is created and begins to-execuie at pn)file manager me ^ntoxi for ProfileMaiaiement- 

Sle P JZ' x . #n „ , .10 Properties objects by calling P_NCF.setContexl(seIected 

anagementPr^perties object. It has the same behavior as a groups which refers to the group of ^ system users, or to 

ProfileManagementProperties object with one exception: n p- *?> wher * a g° U P «mtexl of Development" is 

when preferences are loaded and saved, they are loaded and selected, or to FIG. 21 where a user context "colleend" is 

saved to and from the context of the administrator who is 15 selected. Next, at step 1006, the administrator selects an 

running the profile manager, as opposed to loading and applet to be configured from a list of all the applets on the 

saving to and from the context (i.e., user or user group) for server. See FIG. 17 for an example of selecting an applet. At 

which the administrator is configuring. step 1008, the administrator then clicks a Run/Customize 

The profile manager object needs its preference informa- button to run the applet selected for configuration. This 

tion (i.e., configuration information) so it can tailor the 20 applet might be a separate configuration applet for an end 

profile manager for the administrator is invoking it. To this user applet, or it might be the end user applet itself. The 

end, as part of the profile manager object's initialization selected applet is requested and loaded from the Server at 

process, the profile manager creates a 1009 and 1011. At step 1010, the configuration applet object 

ProfileManagementfroperties_nonContextFloating object is created and begins to execute and to generate its Profde- 

P_NCF at step 914, which is used to load, get, cache, set, 25 ManagementProperties object P. 

and save a copy of the administrator's preference informa- If it is assumed that the applet is a separate configuration 

tion from the server for the profile manager applet. The applet for an end user applet, then at step 1012, the applet 

profile manager object then calls P_NCF.enablePersistence calls p.enablePersistence(configAppletObject, 

(profileManagerObject(applet)), which in step 1 of 916 fuUyQualifiedQassNameOiAppletBeingConfigured). On 

initializes the ProfileManagementProperties 30 the other hand, if the applet is a user applet, rather than a 

nonContextFloating object P _NCF with the URL of the separate configuration applet, the call would be 

profile manager servlet 214. This URL is derived from the p.enablePercistence(endUserApplctObject) since it wants to 

URL of the profile manager 10 applet. The configure its own preference information as opposed to the 

ProfileManagementProperties nonContextFloating object preference information for another applet. The current Con- 

P NCF sends a request 918 to the profile manager servlet 35 text is already known by the ProfileManagementProperties 

214 to get the context name (ID) of the administrator and the object P since it was previously set by the administrator via 

context type (USER). The profile manager servlet gets the the administrator's ProfileManagementProperties 

ID of the administrator from the request (918). The web nonContextFloating object PM NCF. The location of the 

browser passes the administrator ID and password in the profile manager servlet 214 was previously generated when 

message along with the information sent by the 40 enablePersistence was called on the Profile Managers 

ProfileManagementProperties nonContextFloating object ProflfileManagementProperties __nonContextFloating object 

P_NCF. The ProfileManagementProperties PM_NCF. In the case of a configuration applet, the unique 

nonContextFloating object P __NCF is initialized with the key for the applet does not need to be generated because it 
context of the administrator running the applet at step 2 of is passed by the configuration applet to the ProfileManage- 
916. At step 3 of 916, the ProfileManagementProperties_ 45 mentProperties object P in the enablePersistence call. 
nonContextFloating object P __NCF generates a unique key At step 1014, the configuration applet registers itself with 
for the profile manager applet by asking the Java profileM- its ProfileManagementProperties object P as a context 
anagerObject object (passed as a parameter in the enableP- change listener. As discussed earlier, this allows the applet's 
ersistence call) for its fully qualified class name (Le., ProfileManagentProperties object P to notify the applet if the 
profileMaragerObject.getClass( ).getName( )). This unique 50 administrator makes a context change so that the applet can 
key, combined with the administrator's context information, load the preference information for the new context and 
is mapped to specify a unique location in the database 212 update its Graphical User Interface to reflect the new con- 
fer the administrator's specific preference information for figuration information, without requiring that the applet be 
the profile manager applet. terminated and relaunched in the new context 

A request (922) is sent to the profile manager servlet 214 55 Operation continues at FIG. U. At step 1104, the con- 
to get the preference information tailored for the profile figuration applet tells the ProfileManagementProperties 
manager applet as configured for the administrator. The object P to load the preferences from the current context for 
request (922) includes the appropriate context name and the applet being configured. A request 1105 is sent to the 
type and key information to identify the appropriate prefer- profile manager servlet 214 to get the preference 
ence information. The profile manager servlet 214 responds 60 information, tailored for the context previously selected by 
with the requested preference information (924), which is the administrator, for the applet being configured. The 
cached in the ProfileManagementProperties^ request 1105 includes the appropriate context name (the 
nonContextFloating object P_NCF. The profile manager context the administrator has selected) and the context type 
reads its preference information out of the (USER, USER_GROUP, or ALL_USERS_GROUP as 
ProfileManagementProperties_nonContextFloating and 65 appropriate) and key information to specify the location of 
updates itself accordingly (i.e., sets its background color to the appropriate preference information. The profile manager 
blue for example). servlet 214 responds with the requested preference informa- 
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tion at 1106, which is cached in the ProfileManagement- "Applet name" field displays this applet Dame. The "URL" 

Properties object P. The configuration applet gets prefer- (Universal Resource Locator) field displays the Intranet or 

ences from the ProfileManagementProperties object P and Internet web address of this applet on server 202. The field 

updates its Graphical User Interface accordingly. "Complete path of html file" displays the directory path and 

The administrator configures the applet at 1107 and saves 5 ^ e name of the applet in the disk directory structure of 

the modified preferences, for example by clicking a SAVE 202 field " Full y qualified class name** displays 

button provided by the applet. As a result of this operation, me ^ qualified class name of the applet. The field "Icon 

me-configuration applet calls the save( ) method on its ^P 1 ^ a ^b address of the image file used to 

ProfileManagementProperties object p. The ProfileManage- an fi «»«™ a PP"* « a users uesKiop. The 

tTk _ Jr . • . r» i i c , t! remaining fields are for optional information that may be 

mentProperties object P sends the preferences and the 10 « * ■ n r . A 3 , 

, - , . , . / , , . . f required by the software upon invocation. A command 

unique key for the applet being configured and the rnfor- m £ «, Apple! List from Fue", allows the 

mation specifying the current context to the profile manager administrator to append definitions of applets to the existing 

servlet 214. The profile manager servlet stores the prefer- list 1306 from an existing text file. When button 1310 is 

ence information in the database 212 in the location speci- clicked, the window shown in FIG. 14 pops-up and allows 

fied by the Context and the key. 15 me administrator to enter the path and file name of the text 

Step 1108 is an example of the administrator now chang- fi] e containing the applet definitions to be appended. To save 

ing context, while the configuration applet is still running. all pending changes, the administrator clicks on File 1312 

The administrator selects a new context by clicking on a user and then Save (not shown). 

or user group (see FIG. 18 for examples of new contexts in In the left panel, the User Groups item 1302 corresponds 
the administrators left screen panel). As a result of the 20 to the AllUsers group of FIG. 3 ("User Groups** and "AllUs- 
context change, profile manager 506 sends a set context ers" are used interchangeably herein). FIG. 15 shows the 
message to ProfileM angementProperties object P (510) by right panel of the administrators station when the "User 
calling P_NCF.setC6ntext(selected NEW context), which Groups" item 1302 is selected. In FIG. 15, a notebook panel 
in turn causes object P to notify event listener 512 of the is displayed on the right that contains three tabs — a Mem- 
context change via the reload properties API 515. This 25 bers tab 1514, a Subgroups tab 1516 and an Applet Fermis- 
occurs at step 1110. At step 1112, the event listener 512 sions tab 1518. The Members tab is selected in FIG. 15. The 
performs a load( ) call to retrieve the preferences for the new Members panel contains a list 1520 of the log-on identifi- 
context and the object P is updated with the new preferences cations of all members that have been defined to the system, 
at step 1118. The administrator can now proceed to modify To create a new user (who will automatically gain member- 
the new preferences for the new context, if desired, and to 30 ship into the presently selected group context — "User 
save them if required, and then to proceed on with a new Group"), the administrator selects <NEW> from the list 
context change if necessary as described above. 1520, enters the appropriate information in the entry fields 

The remaining FIGS. 12 through 24 show actual screen 1522 to the right of the list, and then clicks on the Create 

snapshots of an administrator's workstation while running button 1522. When an existing member is selected from the 

portions of the profile manager 206. 35 list 1520, the attributes previously saved for that user are 

The main configuration window 1200 is shown in FIG. displayed at 1522. These attributes include the full name of 

12. The tree view panel 1202 on the left of the window the selected member, the member's system ID, password 

depicts profile management 1204 as one of several services and any desired comments. The attributes, except ID, may 

available on the server. When this item 1204 is selected as be edited and the changes committed (but not Saved) by 

shown in FIG. 12, the right panel 1205 of the main window 40 clicking the Modify button 1524, or the user may be 

displays a welcome message for the profile management removed from the system entirely by clicking the Delete 

service. Expand and contract icons such as 1208 are used to button 1526. Any pending change may be removed by 

control the appearance of sub-items under an item in the left selecting the entry in the list 1520 and clicking the Undo 

panel, if any exist. The "+" in 1208 is called an "expand button 1528. 

icon" and indicates that there are sub-items beneath "Profile 45 FIG. 16 shows the administrator's right panel that is 
management". The administrator can display these sub- displayed when the Subgroups tab 1516 is selected. Sub- 
items by clicking on the expand icon 1208, which will then group list 1620 shows existing groups that are subgroups of 
become a "contract icon** ("-"). the item selected in the left panel, which is "User Group" in 
FIG. 13 illustrates an expansion of the Profile manage- this example. Therefore, list 1620 displays all immediate 
ment item 1208 in FIG. 12, which results in the display of 50 subgroups of the "AllUsers" group. In the left panel, "User 
three default sub-items in FIG. 13 — "Applets" 1300, "User Groups'* is expanded. The subgroups shown in list 1620 are 
Groups** 1302 and "Users" 1304. Expansion icons indicate also the expanded items under "User Groups" in left panel, 
that these items can also be expanded. "Applets'* 1300 In list 1620, a status field shows the present status of each 
allows the administrator to define the user applets available subgroup, such as "! delete", "! Modify", and "! Create". An 
on server 202, "User groups" 1302 allows the administrator 55 empty Status field in list 1620 indicates that the subgroup 
to create and populate the user group tree of FIG. 3 and to exists and no actions are pending to be saved. The "!" 
set group preferences. "Users" 1304 allows the administra- symbol indicates that the status is pending (not yet saved), 
tor to create new users and to set their preferences or to Attributes for the subgroup selected in list 1620 appear in 
change preferences for existing users. In the example of 1622. These attributes include the subgroup name and 
FIG. 13 "Applets" 1300 is selected. When this item is 60 desired comments about the subgroup. To create a new 
selected, panel 1305 on the right of the window displays a subgroup, the administrator selects <NEW> from list 1620, 
list 1306 of user applets that have already been defined to the enters the subgroup name and desired comments in 1622, 
system. Attributes of the application that is selected in 1306 and clicks the Create button 1628. An entry of "! create 
are shown at 1308. The administrator defines a new applet <subgroup name>" then appears in list 1620 as a pending 
by selecting <NEW> in 1306 and entering the name and 65 action. To save all pending changes, the administrator clicks 
location information requested in 1308. An existing applet the File button in the top menu bar and then Save (not 
"Database Explorer" is shown selected in 1306. At 1308, the shown). 
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FIG. 17 shows the right panel that is displayed when the or delete an existing member, the administrator clicks on the 

Applet Permissions tab 1518 is selected. List 1720 shows all "Create/Modify/Delete Users" button button 1840. This 

names of all applets that have been defined to the system and action brings up the notebook page shown in FIG. 19. The 

the permission status (permit or deny access) that is assigned right panel of FIG. 19 is similar to that of FIG. 15 and allows 

to each applet for the group or subgroup (the current 5 the administrator to create a new system user by selecting 

"context") that is selected in the left panel. As with other NEW in list 1920 and then clicking the "Create" button, 

notebook pages described, an exclamation point indicates Similarly, the administrator can modify or delete an existing 

that the status depicted is a change that is pending a Save. system user by selecting the appropriate user in list 1920 and 

In FIG. 17, the group "User Groups'* is selected in the tree clicking the appropriate button "Modify" or "Delete". Users 

shown in the left panel, which corresponds to the "AllUsers" 10 created at any subgroup context (e.g., "Development") not 

group shown in FIG. 3. Since all users of the system have only gain the required membership in "User Groups", but 

membership in the "User Groups" group, list 1720 shows the are automatically made members of the selected subgroup, 

global default permissions for all system users for each Changes to the system user list are saved by clicking on 

applet defined to the system. For example, the default "File" in the top menu bar of the right panel and then 

permission status for applet "Database Explorer" is "permit" 15 clicking "Save" (not shown). 

(meaning access is permitted) for the "AllUsers" group; FIG. 20 shows a direct way to get to the system user list 

similarly, the default permission status for all users to applet for editing, rather than through the group and subgroup route 

TFTP is "deny" (access is denied). The administrator can shown in FIG. 19. To get to FIG. 20, the administrator 

change the permission status of an applet by selecting it in selects "Users" 1304 in the left panel of FIG. 13, for 

list 1720 and clicking the "Permit group access" button 1730 20 example. Then in the right panel shown in FIG. 20, the 

or the "Deny group access" button 1732. Furthermore, administrator can create new users and modify and delete 

regardless of an applet's permission status for the selected existing users, as already discussed, without being in the 

context, an administrator can select an applet from 1720 and context of a group or subgroup. 

click the "Run/Customize" button 1734 to execute the user In FIG. 21, the administrator wishes to work directly on 
applet under the selected context. The panel region previ- 25 information corresponding to a user whose ID is "colleend". 
ously showing the notebook for the current context then To do this the administrator expands "Users" in the left panel 
becomes occupied by the executing user applet. If the user of FIG. 21, for example, and then selects "colleend", as 
applet happens to be a configuration applet for other shown. The right panel then appears, which is devoted to 
software, the administrator can then save software prefer- colleend's system information. The right panel contains 
ences (through the configuration applets unique facilities 30 three tabs. The first tab "User Information" is selected by 
provided for this function) which will then be saved as the default. In this tab, the administrator can modify the name, 
software's default preferences for the selected context. If the ID, password and comments pertaining to colleend. 
applet is an end user applet, the functions are the same, FIG. 22 shows the right panel when the administrator 
except the end user applet loads and saves it own preferences selects the second tab "Group Memberships". List 2220 
rather than preferences for a separate piece of software. 35 shows all subgroups of which colleend is a member The 
FIG. 18 shows the complete expansion of the admin is- subgroups are shown in this list in the order of subgroup 
trators left panel subgroup tree beneath "User Groups". priority for colleend. The administrator can change col- 
Immediately beneath "User Groups", there are two sub- leend's subgroup priority by selecting a subgroup and using 
groups "Administrators", a default subgroup that cannot be the up and down arrows to the right of list 2220 to move the 
removed, and "IBM", a subgroup defined by the adminis- 40 selected subgroup up or down the list as desired. If the 
trator. The "IBM" subgroup has also been expanded and administrator clicks the "Add/Remode Group Member- 
contains three subgroups "Hardware", "Services" and "Soft- ships" button 2242 in FIG. 22, the right panel then shows the 
ware". The "Software" subgroup has been expanded and contents of FIG. 23. The FIG. 23 right panel allows the 
contains at least one subgroup called "Development". The adVninistrator to modify the subgroups of which colleend is 
"Development" subgroup contains at least one subgroup 45 a member. The administrator does this by clicking on an 
called NC6D. Subgroup "NCoD" contains a number of appropriate box corresponding to a desired subgroup. If the 
subgroups, such as ConfigFW 58, which have no children. box is clear (meaning that colleend is not presently a 
Also in this example, subgroup "Development" is selected member), then a check mark is added to the box to include 
in the expansion tree. Since "Development" is not at the top colleend in the subgroup. Conversely, if a subgroup box is 
of the tree hierarchy (the "All Users^ group), the notebook 50 already checked, then clicking on the box clears the check 
shown in the right panel is somewhat different from that of mark and removes colleend from the subgroup. 
FIG. 15 when "User Groups" was selected, because all users FIG. 24 shows the right panel when the Applet Fermis- 
are not automatically a member of "Development", as they sions tab of FIG. 22 is selected by the administrator. In this 
are of "User Groups". The list 1820 displays the log-on right panel, list 2420 displays all applets that are defined in 
system IDs of all system members. The status beside each 55 the system. The administrator can permit access by colleend 
user ID in list 1820 shows whether the user owns a mem- to an applet by selecting the applet in list 2420 and then 
bership in the "Development" subgroup. A status of "yes" clicking the "Permit user access" button 2430; or access can 
indicates that the user is a member of the "Development" be denied to colleend by clicking the "Deny user access 
subgroup, "no" indicates that the user is not a member of the button" 2432. The administrator can also launch an applet in 
"Development" subgroup, and "inherited" indicates that the 60 the context of colleend by clicking the "Run/Customize" 
user inherits membership within the "Development" group button 2434. When this is done, the applet selected in list 
by belonging to at least one of Development's subgroups 2420 is launched in the right paneL The administrator can 
further down the tree. A user's membership status for a then modify any preferences that the applet allows and save 
subgroup is modified by the administrator by selecting the the preferences in the manner provided by the applet. A 
user in list 1820 and then clicking on the "Add to Group" 65 typical scenario here is for the administrator to launch a 
button 1836 or "Remove from group" button 1838. If the configuration applet then to fill in a variety of preference 
administrator wishes to create a new system user, or modify fields. However, if a separate configuration is not provided 
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for a user applet, the administrator can launch the user applet 
in the context of a user and set preferences from the user 
applet. A typical scenario here is for the administrator to 
select a group or user context and then to launch the user 
applet as described above. The administrator can then typi- 
cally modify preferences from an options menu and save 
them in any manner provided by the user applet. For 
example, typically, the user preferences are saved when the 
options dialogue is closed, or the" user applet may provide 
other methods of saving the preferences. In any event, since 
the administrator is running the applet in the context of 
colleend in this example, the preferences set up by the 
administrator through the user applet are saved on the server 
as if colleend had entered them directly herself by running 
the applet. 

Not shown in the figures is a scenario whereby a user can 
modify some preferences that pertain to a user applet. For 
example, a user applet may allow a user to select a window 
background color or fonts and font sizes, so that each system 
user can individualize the applet to some extent when the 
user applet executes on the users desktop. In this case, the 20 
user modified preferences are saved in the same way as they 
are when the administrator runs the user applet. One 
difference, however, is that the administrator can run user 
applets to set preferences in group contexts, whereas users 
can only affect preferences for their individual context. 

It is to be understood that the above described arrange- 
ments are merely illustrative of the application of principles 
of the invention and that other arrangements may be devised 
by workers skilled in the art without departing from the spirit 
and scope of the invention. 

What is claimed is: 

1. In a network system comprising a network intercon- 
necting a server and a plurality of user stations, wherein the 
server stores configuration preferences for the end user 
applications in contexts of different groups and subgroups of 35 
users, a method of storing the configuration preferences on 
the server, said method comprising 

providing a profile manager at an administrators station, 
arranging the profile manager to execute a configuration 
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server stores configuration preferences for the end user 
applications in contexts of different groups and subgroups of 
users, an arrangement for storing the configuration prefer- 
ences on the server, comprising 

a profile manager at an administrators station, 
means allowing the profile manager to execute a configu- 
ration application for an end user application, whereby 
the administrator can specify configuration preferences 
for the end user application liTcon'texts of different 
groups and subgroups of system users, 
means for determining a unique location on the server for 
storing the configuration preferences for the end user 
application in a selected context, including 
means for retrieving a fully qualified class name of the 
end user application from an object on the adminis- 
trator's station which represents the configuration 
application, whereby the fully qualified class name 
uniquely differentiates the application from other 
object classes, 
means for combining the fully qualified class name 

with the selected context to form a key, and 
means for mapping the key in a prescribed manner to 
generate the unique storage location address. 

4. The arrangement of claim 3 further comprising 
means at a user's station responsive to a request to execute 

a user application for requesting from the server a user 
context, 

means at the user station for combining the context with 
the fully qualified class name of the user application to 
form the key, and 

means at the user station for requesting configuration 
preferences for the application by sending the key to 
the server to identify the storage location of the pref- 
erences. 

5. A computer storage media having program code seg- 
ments stored thereon for use in a client-server network 
having a server and a plurality of user stations for deter- 
mining a unique server storage address for storing configu- 
ration preferences for end user applications in contexts of 



application for an end user application, whereby the 40 different groups and subgroups of users, the media compris- 



administrator can specify configuration preferences for ing 
the end user application in contexts of different groups 
and subgroups of system users, 

determining a unique location on the server for storing the 
configuration preferences for the end user application 
in a selected context by 

retrieving a fully qualified class name of the end user 
application from an object on the administrator's sta- 
tion which represents the configuration application, 
whereby the fully qualified class name uniquely differ- 
entiates the application from other object classes, 

combining the fully qualified class name with the selected 
context to form a key, and 

mapping the key in a prescribed manner to generate the 
unique storage location address. 

2. The method of claim 1 further comprising 
at a user's station, responsive to a request to execute a user 

application, requesting from the server a user context, 
at the user station, combining the user context with the 60 
fully qualified name of the user application to form the 
key, and 

requesting configuration preferences for the application 
by sending the key to the server to identify the storage 
location of the preferences. 65 

3. In a network system comprising a network intercon- 
necting a server and a plurality of user stations, wherein the 
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a first code segment for providing a profile manager at an 

administrators station, 
a second code segment for arranging the profile manager 
to execute a configuration application for an end user 
application, whereby the administrator can specify con- 
figuration preferences for the end user application in 
contexts of different groups and subgroups of system 
users, 

a third code segment for retrieving a fully qualified class 
name of the end user application from an object on the 
administrator's station which represents the configura- 
tion application, whereby the fully qualified class name 
uniquely differentiates the application from other 
object classes, 
a fourth code for combining the fully qualified class name 

with the selected context to form a key, and 
a fifth code segment for mapping the key in a prescribed 
manner to generate the unique storage location address. 
6. The media of claim 5 further comprising 
a sixth code segment for use at a user station and 
responsive to a user request to execute an application 
for requesting from the server a user context, 
a seventh code segment for use at the user station for 
combining the user context with the fully qualified 
name of the user application to form the key, and 
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an eighth code for use at the user station for requesting 
configuration preferences for the application by send- 
ing the key to the server to identify the storage location 
of the preferences. 
7. A computer program embodied in a carrier wave and 
containing program code segments stored for use in a 
client-server network having a server and a plurality of user 
stations for detenmning a .unique, server storage.address for_. 
storing configuration preferences for end user applications in 
contexts of different groups and subgroups of users, the 
program further comprising 

a first code segment for providing a profile manager at an 

administrators station, 
a second code segment for arranging the profile manager 
to execute a configuration application for an end user 
application, whereby the administrator can specify con- 
figuration preferences for the end user application in 
contexts of different groups and subgroups of system 
users, 

a third code segment for retrieving a fully qualified class 
name of the end user application from an object on the 



10 



15 



20 



24 



administrator's station which represents the configura- 
tion application, whereby the fully qualified class name 
uniquely differentiates the application from other 
object classes, 

a fourth code for combining the fully qualified class name 
with the selected context to form a key, and 

a fifth code segment for mapping the key in a prescribed 
manner to generate the -unique storage-location address. 

8. The computer program of claim 7 further comprising 

a sixth code segment for use at a user station and 
responsive to a user request to execute an application 
for requesting from the server a user context, 

a seventh code segment for use at the user station for 
combining the user context with the fully qualified 
name of the user application to form the key, and 

an eighth code for use at the user station for requesting 
configuration preferences for the application by send- 
ing the key to the server to identify the storage location 
of the preferences. 



